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METHOD AND SYSTEM FOR NOTIFYING CUSTOMERS OF TRANSACTION 

OPPORTUNITIES 

CROSS-REFERENCE TO RELATED APPLICATIONS 

5 The current application claims priority to provisional application number 60/197,773 

filed April 14, 2000 entitled, "METHOD AND SYSTEM FOR NOTIFYING CUSTOMERS 
OF TRANSACTION OPPORTUNITIES " which is incorporated herein by reference in its 
entirety. 

10 BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates to financial transaction notification systems and methods, 
generally. Particularly, this invention relates to systems and methods for collecting, 
monitoring, and comparing data to customer requests. 

15 

Description of Related Art 

Prior to the current invention, available event notification systems included, for 
example, local desktop notification systems, such as e-mail alerts or instant messaging alerts 
which alert a user through a visual or audio signal that a new e-mail or instant message has 
20 arrived and is available for retrieval within the users local computer network. These alerts 
merely indicate that a message is available for viewing, the alerts do not provide the substance 
of the message. 

Other event notification systems alert a user via, for example, an e-mail message, of the 
availability of certain information, solicited or unsolicited, on the Internet or World Wide Web 
25 through a specified Web site or universal resource locator ("URL"). An unsolicited notification 
includes, for example, the availability of an electronic greeting card (e^ 
www.bluemountain.com). A solicited notification provides notification of the availability of 
information that was specifically requested by the user. For example, at www.realtor.com, a 
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registered user can request notification of homes for sale according to pre-defined user 
parameters, e^g., location, price, number of bedrooms. When homes meeting the registered 
user's parameters are listed on the www.realtor.com Web site, the Web site sends an e-mail to 
the registered user indicating that there are homes available for sale fitting the user's parameters 
5 and providing the link to the Web site in the e-mail. These types of notification systems are 
limited to one method of notification, e-mail. Further, the notification system is not linked to 
any other type of user information, such as user financial information, ej^., bank accounts, 
credit accounts, investment accounts, that is constantly variable due to the actions of the user, 
i.e., the actions of the user do not result in a triggering of the alert. 

10 Finally, there are notification systems available wherein a user's local computer is 

equipped with a data filter that receives and searches incoming data messages, e^., e-mail 
messages, intended for the user, for predetermined event information. When the data filter 
identifies the predetermined event information, a local event indicator, e.g., audio and/or visual, 
is presented through the user's local computer indicating that a previously specified event has 

15 occurred. The user then has a specified amount of time, e.g., 10 seconds, to acknowledge the 
local event indicator by, for example, clicking on the provided visual alert, e^., icon. If the 
user does not acknowledge the local event indicator within the specified amount of time, the 
user's computer establishes a connection with a server in order to remotely notify the user of 
the event through a notification method of the user's choice, such as, pager, telephone, or 

20 personal digital assistant ("PDA"). This notification system is limited to searching and 
retrieving local event information from user-intended messages, ejjy Web pages pushed to a 
users e-mail address. Further, the local events, though pre-defined and requested, are not 
triggered by user actions, such as financial transactions. 

25 BRIEF SUMMARY OF THE INVENTION 

Consequently, there is a need in the art for a notification system that is directly linked to 
the actions of the user, in addition to the pre-defined parameters selected by the user, wherein 
such a system collects data independent of any electronic address of the user, Le., information 
searched for the requested alert is not limited to messages directed to the user. Further, there is 

30 a need for a notification system wherein the requested alerts are triggered based on the values of 
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private customer-specific financial information, such as bank account, credit card, or brokerage 
portfolio information. 

Various embodiments of the present invention comprise a standalone notification 
system, including a notification server which generates electronic messages to registered 

5 customers upon their request or upon a host business request. A customer provides the system 
with his/her messaging identification ("ID"), e.g. e-mail address, GSM (global system for 
mobile communications) or other mobile phone numbers that are able to accept, e^ short 
message service ("SMS") messages, facsimile number, and/or telephone number. Customers 
can register with the host notification server without having any relationship, banking or 

10 otherwise, with the host. Customers can choose between different notification channels such as 
e-mail, SMS message, fax or pager. 

Further embodiments of the present invention comprise a notification system, which 
allows host personnel, such as customer service representatives ("CSR"), to create and maintain 
customer requests on behalf of a customer. 

15 The design of the notification system is geared toward scalability and performance. The 

notification system ensures a scalable architecture by using a stateless Web site and distributed 
architecture. The use of a stateless Web site results in increased available memory. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 

Figure 1 is a schematic view of a notification system according to an embodiment of 
the present invention; 

Figure 2 is a schematic view of a Web page according to an embodiment of the present 
invention; 

25 Figure 3 is a schematic view of Web page according to an embodiment of the present 

invention; 

Figure 4 is a schematic view of a Web page according to an embodiment of the present 
invention; 

Figure 5 is a schematic view of a Web page according to an embodiment of the present 
30 invention; 
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Figures 6(a) and 6(b) are schematic views of a Web page according to an embodiment 

of the present invention; 

Figure 7 is a schematic view of a Web page according to an embodiment of the present 

invention; 

Figure 8 is a schematic view of a Web page according to an embodiment of the present 
invention; 

Figure 9 is a schematic view of a Web page according to an embodiment of the present 
invention; 

Figure 10 is a schematic view of a Web page according to an embodiment of the 
present invention; 

Figure 11 is a schematic view of a Web page according to an embodiment of the 
present invention; 

Figure 12 is a schematic view of a Web page according to an embodiment of the 

present invention; and 

Figure 13 is a flowchart illustrating a typical process flow when using a notification 
system according to an embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

The notification system embodied by the present invention is capable of multiple 
avenues of access to and from multiple parties. Further, the notification system utilizes 
multiple databases which are fed information via the multiple parties and/or via other servers 
and/or back office host systems, such as readable files which are updated by running an 
appropriate executable program. 

In an embodiment of the present invention, all live financial information comes from 
one or more host computers operated by the host financial institution. The information 
provided by these hosts is presented to the databases and the alert message generators included 
in the notification system in the form of a "host handoff file" (See FIG. 1). This file represents 
a data dump from the host database of all information relevant to subscribers on the notification 
system. These host handoff files may be presented periodically (e&., once a day) or they can be 
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represented as a live real-time connection between the back office host processor(s) and the 
notification system. 

In at least one embodiment of the present invention, a preferred medium for facilitating 
all of the customer configuration interactions described below is a public access network, such 
5 as the Internet or World Wide Web, due to such a network's far-reaching, efficient and 
expeditious characteristics for data transmission and presentment. A particularly effective 
method of displaying and generating data and information is through the use of Web sites 
and/or Web pages. While the specific schema illustrated in the tables printed below provide the 
necessary format for collecting and synthesizing data within the databases themselves, the 

1 0 requests for data which are made to or by the customers or CSRs are made through a more user- 
friendly and recognizable format such as a graphical user interface ("GUI"). 

In at least one embodiment of the present invention, multiple Web sites are provided to 
facilitate data collection and presentation. The following, which are in no way intended to be 
limiting, represent Web sites and Web pages used in a preferred embodiment of the present 

15 invention: non-member customer ("NMC") preference site; member customer ("MC") 
preference site (e.g., CITIDIRECT® customer preference sub applications ("MiniApps") and 
Transaction executors); CSR preference site; product information, rates and host messages 
maintenance site; notification reports site; system maintenance site; and database access 
security site. 

20 In an embodiment of the present invention wherein a sponsoring financial institution or 

host (hereafter "host") maintains the notification system, the host establishes a central Web site 
(e.g., homepage) as an advertising and explanatory mechanism as well as the conduit through 
which MCs, NMCs, and CSRs are able to access their respective login Web pages. The format 
of the Web sites and Web pages may be HTML, XML, or the like. Depending on which type 

25 of customer is attempting to gain access, the customer selects the appropriate link, which links 
them to a login Web page. Once presented with the selected Web page, the user may be further 
prompted to select between a "first-time user" and a "repeat user" login link. The difference 
between these two login links being the amount of information which needs to be entered prior 
to granting the user access to the preference sites. 

30 Referring to FIG. 1, the notification system 10 is comprised of a system of servers and 

databases which are accessed via the Internet, through various Web sites, such as a 
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CITIALERT™ non-member Web site 12 and/or a CITIDIRECT® member Web site 14, and a 
CITI ALERT™ maintenance Web site 110. Since the present invention, though affiliated with 
one or more hosts, does not require that the customers accessing or using the notification 
system actually have a financial relationship with any one of the controlling hosts, Web site 12 
5 may be used by all customers, including non-member customer ("NMC") (e.g., customers who 
do not have a relationship with the affiliated host or hosts) while Web site 14 provides access to 
the notification system 10 to member customers ("MC") only. Web site 110 is used by 
employees of the hosting financial institution to configure the alert system. 

Web sites 12, 14 and 110 feed information, directly and indirectly, to a number of 

10 sources. The Web sites 12 and 14 are sources of configuration information related to the 
specific configuration parameters for each customer (both member and non-member users). 
The Web site 110 feeds additional configuration information into the system. This Web site is 
only useable by host employees, and provides configuration information about the nature of the 
notifications; the text of the notifications; the manner of notification (email, SMS, etc.); and 

15 similar system wide configuration information. As discussed below, the invention also 
contemplates accessing external sources of information. One or more back office host 
processors 18 provide host handoff files to a host handoff files database 16 which include 
information that feeds into the customer preference database 24, the alert message text database 
26, and the rates and information database 30; and which, in some cases, are processed directly 

20 by the alert message generators 32. The information provided by MCs and NMCs to Web sites 
12 and 14 is fed into a database containing customer preferences 24. The information provided 
by the host's maintenance personnel to Web site 110 is fed into the same database containing 
customer preferences 24, as well as the alert message text database 26 and, potentially, the rates 
and information database 30. The host-handoff files 16 are fed to all of these databases. 

25 Finally, in an embodiment of the present invention, the system uses externally generated data 
from external sources 28. These externally generated sources include Internet based sources, 
contracted sources via private lines or any other available sources. They feed information into 
the rates and information database 30. The rates database contains information including, for 
example, interest rates and fees on loans and credit cards, interest rates on deposit accounts, 

30 foreign exchange rates, etc. The information database contains information including, for 
example, product information, corporate news, new products or services, etc. 
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Given the three databases, customer preference 24, alert message 26, and rates and 
information 30; as well as the information in the host handoff files database 16, alert message 
generators 32 access the information therein, to form a rates and information alert message 
generator 34 and a host alert message generator 36. These alert message generators 32, 

5 generate the messages requested by the customers, which are stored in an alert message text 
database 26 prior to being sent to a customer selected alert message gateway 40. As discussed 
below, these gateways may include but are not limited to e-mail 42, HTML (hypertext mark-up 
language) 44, pager 46, CSR call 48, mobile phone text messaging, e^., Global System for 
Mobile Communications Service ("GSM") 50, and XML (extensible mark-up language) 52, 

1 0 facsimile 54, and short message service ("SMS") 54. Through these alert message gateways 40, 
requested information is transmitted to the customer 58. 

In embodiments of the present invention, multiple servers may be grouped according to 
the particular databases into which they are feeding data and information. While not explicitly 
depicted in the Figures, these servers or feeders are executables that are run through, for 

15 example, the system maintenance site, in order to continually update the databases within the 
notification system. For example, a customer profile server and a rates server both update the 
customer preference database 24. Similarly, the same rates server and a host handoff server 
update the host handoff files database 16. While not explicitly depicted in the Figures, the 
customer profile, rates, and host handoff servers are executables that are launched, for example, 

20 through the system maintenance server/site 110. By way of example, prompted by the system 
maintenance server/site 110, in a specific embodiment of the present invention, the servers read 
selected information from the up-to-date host handoff files, format the selected information 
according to a command program and update the aforementioned databases, respectively. 
Further in this specific embodiment, the customer profile server's functionality is to keep up to 

25 date customer profile and customer relationship data. As will be discussed further later in this 
disclosure, the customer profile server updates only host customer records, such that only MC 
and not NMC notification set-ups are affected by this server. The host handoff and rate servers 
functionalities are to import host generated events and to keep the rate related information up to 
date, respectively. 

30 The alert message generators 32 contemplated by at least one embodiment of the present 

invention include, a rates and information alert message generator 34 and a host alert message 
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generator 36. Message generators are designed to analyze the customer's preferences against 
current rates, product information and host handoff data and create entries within the alert 
message text database 26. 

The rates and information message generator(s) 34 is an executable which has direct 
5 access to the customer preference database 24, to rates and information database 30 and to alert 
message text database 26 through database access security server. These executables populate 
the alert message text database 26 with notification requests based on customer preference 
specification and rates and info content. Each request record indicates the customers preferred 
notification channel i.e., alert message gateway. The message generators create the actual 

10 message phrases taking into consideration the type of transaction they are reporting on. 

The host alert message generator(s) 36 is an executable which has direct access to the 
customer preference database 24, to host handoff files database 16 and to alert message text 
database 26 through the database access security server. These executables populate the alert 
message text database 26 with notification requests based on customer preference specification 

15 and host handoff results. Each request record indicates the customer's preferred notification 
channel. The message generators create the actual message phrases taking into consideration the 
type of transaction they are reporting on. The alert message gateways 40 are executables which 
extract the content from the alert message text database 26 based on the customer's preferred 
notification channel and forward them to the corresponding gateway. Forwarded messages are 

20 moved from a "work" table to an "audit" table within the same database. Specific alert message 
gateway agents will be written for each notification channel such as the FAX or the SMTP 
(simple mail transfer protocol) mail. In preferred embodiments of the present invention, a web- 
based product information, rates and host messages maintenance site is provided to update 
individual rates records, information records, host product records, and to report on statistical 

25 usage of the product database. This site is also used to enter the specific response messages 
sent to the customer for each event. 

In preferred embodiments of the present invention, a web-based reports server/site 100 
is used to generate MIS (management information system) and marketing reports on the 
customer preference database 24 and alert message text database 26. The web-based system 

30 maintenance server site 110 is used to backup, archive, restore and report on statistical usage of 
all databases within the notification system 10. This system maintenance server/site 110, in 
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addition to the configuration operations discussed above, is also used to launch and control 
different server executables and different alert message generators 32. Finally, a web-based 
database access security server/site 120 is used to control access to databases and servers within 
the notification system 10. This database access security server/site 120 gives a requesting 
5 server the proper database connection string, database login ID, and PASSWORD. The 
database access security server/site 120 has administrator privileges over all the databases. This 
server/site 120 solves the problem of hard coding the database login IDs into the operating 
system registry. 

Referring to FIG. 2, MCs, NMCs, and CSRs may enter information through Web site 

10 12. In particular, Web site 12 prompts MCs to login by clicking on a first link 11, Web site 12 
prompts NMCs to login by clicking on a second link 13 and Web site 12 prompts CSRs to login 
by clicking on a third link 15. Referring to FIG. 3, by clicking on the first link 11, an MC is 
linked to the login Web page 17 for MCs, where the MC is directed to a first-time customer 
login link 19 and a repeat customer login link 21. Referring to FIG. 4, selection of the repeat 

15 customer login link 21, results in Web page 23. Web page 23 prompts the MC for an ID name 
25 and a PASSWORD 27. MCs ID name 25 and PASSWORD 27 were established during a 
first-time login sequence, discussed below. 

Again, referring to FIG. 3, an MC who is a first-time MC, selects first-time customer 
login link 19. Referring to FIG. 5, selection of link 19 results in Web page 29 which prompts 

20 the first-time MC for various information, including, but not limited to, customer's LAST 
NAME 31, customer's ACCOUNT NUMBER 33 (e.g., checking, savings with the host), 
personal identification number ("PIN") 35, customer selected ID name 37, customer selected 
PASSWORD 39, a repeat of the PASSWORD for verification 41, and customer's E-MAIL 
ADDRESS 43. Additionally, in an alternative embodiment discussed further below, the first- 

25 time customer login page also requests payment information (not shown). At least one 
embodiment of the present invention contemplates that a MC will have access to more types of 
notification requests than a NMC, due to the pre-established relationship with the host. As a 
result of this relationship, the MCs private financial information may be utilized in fulfilling a 
notification request. As such, at least one alternative embodiment requires a PIN previously 

30 generated by the host for the MC, which adds a level of protection to the private financial 
information (e.g., account numbers). 
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Further alternative embodiments require that the MC pay a host-determined fee 
depending on various factors, such as the number of notification requests, the type of 
notification requests, and/or the MC's current financial relationship with the host. In a 
particular alternate embodiment, the host requires a minimum cumulative balance of, for 

5 example, $10,000.00, including all of the MC's accounts with the host in order to avoid paying 
a fee for the notification service. In the case where the MC's balance is less than $10,000.00, 
the host charges the MC a flat monthly fee for using the notification service. These charges are 
assessed to, for example, the MC's credit card, wherein the MC provides credit card 
information during the registration process (FIG. 5). One skilled in the art recognizes that 

1 0 alternative fee arrangements fall within the scope of this invention. 

Referring to FIG. 6(a), upon successful login by an MC, the MC is linked to MC 
preference site 70 which utilizes a MiniApp and Transaction Executors. Further, fill-in forms, 
similar to those used in, for example, the CITIDIRECT® home banking system are used to 
collect MC data such as content to be notified on 72, preferred channel of contact 74, and a 

15 preferred time for notification 76. By way of example, the content to be notified on may 
include, but is not limited to information relating to the MCs checking, savings and portfolio 
values, interest rates, stock quotes, credit specials (e.g., special loans, low credit card rates) and 
other financial specials offered by the host. Specific account-notifications can include, but are 
not limited to, past-due-date reminders, overdrafts, credit limits, specific credit charges (e^, 

20 single amount charges, location charges), credit fraud warnings (e^g,, based on unfamiliar 
pattern of charges, location of charges, amount of charges) direct deposits (e,g., of salary, 
dividend, etc.), balance, credit card due dates, automatic bill payments, check clearing alert and 
ATM withdrawals. The preferred channel of contact may be selected from e-mail, HTML, 
pager, CSR, mobile phone text messaging, e^, GSM, XML, facsimile, and SMS. The MC 

25 may request to be notified at specific times such as instantaneously (e^g., as soon as 
technologically possible when the requested event occurs), hourly, daily, weekly, or monthly. 
In alternative embodiments, the MC is able to select different notification times for different 
events. After making general notification selections via the MC preference site 70, the MC is 
linked to other Web pages (not shown) via the "CONTINUE" icon where they are able to 

30 provide more specific request information (e.g. phone #, fax #, requested interest rate, requested 
account balance information, etc.). The Transaction Executors have direct access to the 
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internal databases and servers of the host (e.g. CITIGOLD® server), subject of course to 
Database Access Security server restrictions (discussed below). MCs have more options to 
select from, which are not available to NMCs, through MC preference site 70. Further, the MC 
preference site 70 is capable of generating reports 78. 
5 Referring to FIG. 6(b), in an embodiment of the present invention, when the MC clicks 

on the "CREATE REPORT 55 link 78, the MC is directed to a separate "Report Parameters" Web 
page 200 for defining report parameters. The "Report Parameters" Web page 200 facilitates 
user-defined reports 205, where the MC has the ability to define what type of report the MC 
would like to have created from the information contained in the notification system, as well as 

10 predetermined parameter reports 210. Predetermined parameter reports 210 include, for 
example, today, daily, weekly, monthly notification reports which list all notifications sent 
during the current day for today and the immediate preceding specified time frame e.g. , 
preceding day, preceding week, preceding month for daily, weekly, and monthly notification 
reports. Further, the predetermined parameter reports 210 show all methods by which the 

15 notifications were sent as well as a summary of the notification, e.g. , "$1,000 deposited into 
account no. XYZ on MM/DD/YY." User-defined reports 205 allow the user to specify 
parameters used to create the report from specific dates and date ranges to specific accounts, to 
specific notification methods through which the specified notifications were sent. Once the MC 
selects their desired report parameters or predetermined parameter report, clicking on the 

20 "GENERATE REPORT" button 215 results in a report which includes the desired parameters. 

In an embodiment where a NMC enters the initial Web site 12, the NMC selects link 13 
which, referring to FIG. 7, links the NMC to the NMC login Web page 45 which prompts the 
NMC to select between a first time customer login link 47 and a repeat customer login link 49. 
Additionally, Web page 45 may offer a link to the host's homepage 51, in order to familiarize 

25 the NMC with the other services offered by the host, with a reminder that the notification 
system offers a wider range of services to MCs. Selection of repeat customer login link 49 
links the NMC to the repeat customer login Web page 53, as show in FIG. 8, where the NMC is 
prompted to enter previously selected ID name 55 and PASSWORD 57. 

Alternatively, referring to FIG. 9, when the NMC selects the first-time customer login 

30 link 47, the NMC is linked to the first-time customer login Web page 59, where the NMC is 
prompted to enter some or all of the following information including customer's FULL NAME 
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61, customer's selected ID Name 63, customer's selected PASSWORD 65, repeat of 
PASSWORD for verification 67, and customer's E-MAIL ADDRESS 69. Referring to FIG. 
10, upon successful login, the NMC is linked to a stateless NMC preference site 80 which uses 
an HTML form to collect customer data such as content to be notified on 82, preferred channel 
5 of contact 84, and preferred time for notification 86. By way of example, the content to be 
notified on may include, but is not limited to information relating to interest rates, mortgage 
rates, stock quotes, credit specials (e.g., special loans, low credit card rates) and other financial 
specials offered by the host. The preferred channels of contact 84 and the preferred times for 
notification 86 are similar to those listed with reference to 74 and 76. After making general 

10 notification selections via the NMC preference site 80, the NMC is linked to other Web pages 
(not shown) via the "CONTINUE" icon where they are able to provide more specific request 
information (e.g. phone #, fax #, requested interest rate). This NMC preference site 80 does 
not generate any reports and financial account information is not accessible through this site. In 
an alternative embodiment, prior to gaining access to the NMC preference site 80, the NMC is 

15 required to provide payment information in order for the host to charge the NMC for the 
notification service. In this embodiment, the NMC provides, ejj.? credit card and billing 
information to the host. The host establishes a desired method and time for payment, e.g., flat 
monthly fee, fee based on number of alerts, fee based on type of alerts (see below). 

In a further alternative embodiment, the host provides the NMC with the same alerts 

20 that are provided to the MC. In this alternative embodiment, the host uses either pre- 
established lines of communication, such as ATM lines, credit authorization lines, settlement 
lines (e.g. , Automated Clearing House) and/or specifically negotiated and established lines of 
communication, in order to obtain the NMC's financial information from the NMC's financial 
institution. Referring to FIG. 1, the NMC's financial information is obtained through external 

25 sources 28 and stored in the rates and information database 30. For example, a customer with a 
single checking account at Chase Manhattan signs onto the notification system hosted by 
CITIBANK and requests that the notification system alert the customer via SMS 
instantaneously when the customer's checking account balance is below $1,000.00. In this 
alternative embodiment, the NMC is provided with some or all of the notification options that 

30 are available to the MCs. In order to provide this alert, CITIBANK cannot use its internal 
sources. Consequently, referring to FIG. 10, when the customer selects the "CONTINUE" 
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button, the customer will be queried for all identifying information necessary to complete the 
alert. In this example, the customer supplies information that identifies the customer and the 
customer's account to Chase Manhattan so that Chase Manhattan can release the customer's 
information to CITIBANK. This information includes, for example, the customer's CIN, the 
5 customer's checking account information, including account number, as well as Chase 
Manhattan's identifying information, such as bank routing number or bank identification 
number ("BIN"). Using this identifying information, CITIBANK establishes a standing request 
to Chase Manhattan to send the customer's checking account to CITIBANK whenever there is a 
change in, for example, the amount in the customer's checking account. When the updated 

10 checking account information is received at CITIBANK, the updated checking account 
information, e.g. , balance, is compared to the customer's request and if the balance is below 
$1,000.00, the CITIBANK notification system formulates a notification message and sends the 
message to the customer using SMS. If the balance is at or above $1,000.00, no message is 
formulated and the notification system waits for the next update. 

15 As with the MCs and the NMCs login, the CSRs are also able to access the notification 

system through the Web site 12. A CSR selects the CSR login link 15 on Web site 12. CSR 
login link 15 links the CSR to login Web page 71, wherein the CSR is prompted to enter 
identification information, such as CSR Name 73 and CSR NUMBER 75, as shown in FIG. 11. 
Unlike the login choices presented to the MCs and the NMCs in FIG(s). 3 and 6, the CSR is 

20 not offered a first-time login link. The CSR must already have been assigned the appropriate 
identifiers prior to entering the login Web page in order to successfully login to the notification 
system 10. 

Referring to FIG. 12, upon successful login, CSRs are linked to a CSR preference site 
90, where the CSR is able to create customer requests 92 and set notification channel options 94 

25 and notification time options 98 on behalf of the customers, e.g. , MCs and NMCs. CSRs enter 
the customer's Customer Identification Number (CIN) 96 in order to access previously entered 
customer information files or to create new files under this CIN. By way of example, the 
content to be notified on may include, but is not limited to information relating to the MCs 
checking, savings and portfolio values, interest rates, stock quotes, credit care charges (e.g. , 

30 over a specified amount, made in a specified geographic region, made in a specific retail store) 
automatic bill payments (e.g. , car loan, mortgage, school loans, telephone, utilities, insurance, 
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and the like), ATM withdrawals, credit specials (e.g., special loans, low credit card rates) and 
other financial specials offered by the host. After making general notification selections via the 
CSR preference site 90, the CSR is linked to other Web pages (not shown) via the 
"CONTINUE" icon where they are able to provide more specific request information (e.g. 
5 phone #, fax #, alert customer when home mortgage rates reach X%). 

By way of example, in FIG. 13 a method of practicing the invention begins with a 
customer entering an initial Web site (e.g., CITIALERT™ Web site) maintained by the host 
(e.g., CITIBANK™) (SI). The Web site prompts the customer to select the icon which reflects 
the customer's status as either a MC or a NMC (S2). If the customer selects the NMC icon, the 

10 NMC is linked to the NMC login Web page (S3). The NMC login Web page queries the NMC 
as to whether or not this is their first login attempt (S4). If this is the NMCs first login attempt, 
the NMC selects the appropriate icon, is linked to the first-time login Web page, and provides 
the requisite information (S5). Assuming the NMC has logged in at some previous time, the 
NMC selects the repeat customer icon and enters the appropriate ID Name and PASSWORD 

15 (S6). After logging in, the NMC is directed to the stateless NMC preference site where the 
NMC is prompted to select message and notification information (S7). 

If in response to (S2) the customer selects the MC icon, the MC is linked to the MC 
login Web page (S8). The MC login Web page queries the MC as to whether or not this is their 
first login attempt (S9). If this is the MCs first login attempt, the MC selects the appropriate 

20 icon, is linked to the first-time login Web page, and provides the requisite information (S10). 
Assuming the MC has logged in at some previous time, the MC selects the repeat customer icon 
and enters the appropriate ID Name and PASSWORD (Sll). After logging in, the MC is 
directed to the MC preference site (e.g., CITIDIRECT® site) where the MC is prompted to 
select message and notification information (S12). 

25 Within both the NMC preference site 80 and the MC preference site 70, respectively, 

the customers are prompted to choose and provide information relating to a message they would 
like to receive and also to select the notification alert message gateway 40 through which they 
would like to be alerted of the message (S13). This information is saved by the notification 
system 10 within the host-handoff files 16, (S14). The host-handoff files 16 are accessed by 

30 multiple servers (see FIG. 1) and data therefrom is compiled into specific request and 
notification files (S15). The specific requests are compared to continuously incoming 
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information from internal and external sources (S16), The notification system 10 ascertains if 
there is a match (S17). If there is a match, the customer is notified according to the customer's 
request, through the customer's selected gateway (SI 8), If there is no match, the request is 
compared to the next bit of incoming information (S19), until the request is fulfilled. 
5 The notification system 10 described above is capable of alerting customers in multiple 

transaction areas. In embodiments of the present invention, MCs enjoy a wider range of 
possible notification scenarios, due to their financial relationship with the host. For example, 
MCs may be alerted as to account balances, CD maturation, credit card payment being due, a 
check has bounced, foreign or domestic exchange has hit a target price, foreign exchange rates, 

10 domestic interest rates, etc. Either the MC or a CSR would enter the appropriate preference cite 
and proceed to enter the request. In an alternative embodiment, if the MC has a broker 
relationship with the host, an embodiment of the present invention contemplates a multiple alert 
scenario, wherein, for example, the MC requests notification when a particular stock hits a 
specified value. This is the first alert. The MC further instructs the host broker at the time of 

15 establishing the first alert, to buy X shares of the stock, using funds from a specified account, 
when the stock value reaches this specified value. The host broker sends a second alert 
notifying the MC that the transaction has been completed. Alternatively, after sending the first 
alert, instead if purchasing the stock automatically, the host broker is instructed by the MC to 
wait for a reply message from the MC prior to purchasing the stock. Although more restricted 

20 in the types of alerts that they may receive in certain embodiments, NMCs may still be alerted 
regarding for example, interest rates and stock prices. 

In various embodiments of the present invention all of the customers of the notification 
system 10 create their own login IDs and PASSWORDS through a web application interface in 
order to access the notification system 10 via the Internet. Customer login IDs and 

25 PASSWORDS are subject to creation business rules and are checked for uniqueness. The web 
application login IDs are independent of any host ID such as host account numbers, or CINs in 
the case of MCs. The PASSWORDS are kept in encrypted format. In the case of NMCs, the 
ID and PASSWORD may only grant them limited access to the notification system 10. In 
alternative embodiments, the MCs may have access to other levels or databases within the 

30 notification system due to their membership status. In order to access these databases, in 
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addition to their self-created IDs and PASSWORDS, MCs are prompted to enter additional 
identifying information such as, account numbers or CINs. 

In various preferred embodiments of the present invention, once the customers have 
created IDs and PASSWORDS, the notification system 10 offers multiple avenues for alerting 
5 or notifying the customers of financial opportunities to which they might wish to avail 
themselves. Referred to herein as alert message gateways 40, these include but are not limited 
to electronic mail ("E-mail") 42, mobile phone text messaging, e.g. , Global System for Mobile 
Communications Service ("GSM") 50, facsimile ("Fax") 54, extensible mark-up language 
("XML") 52, hypertext mark-up language ("HTML") 44, pager service 46, and short message 

10 service ("SMS") 56. Additionally, personal contact methods may also be chosen, such as 
person-to-person calls with CSRs 48. In the event that a particular notification gateway 40 is 
not specifically selected, an embodiment of the present invention provides a default notification 
gateway, for example, the customer's e-mail address. In this embodiment, the e-mail address of 
the customer would be a required field that must be completed prior to enrollment into the 

1 5 notification system. 

In various embodiments of the present invention, customers access the notification 
system 10 for any of a variety of reasons. Customers may choose to access the notification 
system 10 in order to add new or updated information to one or more of the available databases. 
In particular, customers may wish to choose or change their preferences for when and how they 

20 wish to be notified of transaction opportunities. Further, customer's may wish to check a log or 
report of the most recent notifications that they have received. For example, an embodiment of 
the present invention allows customers to check a report containing the last X (X = 1, 2, 3....n) 
notifications of which the customer was alerted via their chosen notification gateway 40. 
Further as discussed with reference to FIG- 6(b), the report may contain a more detailed 

25 account of the substance of the notification for the customer to review prior to acting or not 
acting based on the information contained in the notification. 

Embodiments of the present invention allow host personnel or CSRs to access the 
notification system 10, in addition to customers accessing the notification system. CSRs, 
including host telephone operators, are able to create or update customer records through, for 

30 example, a web application interface. These additions or updates may be added in response to a 
customer call, either after the call or simultaneous therewith. In an alternative embodiment, the 
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CSR accesses the notification system 10 to enter customer record information that has been 
collected from other off-line sources, such as from customer paperwork that has been 
completed by the customer for host service enrollment, e.g. opening new accounts, applying for 
loans, etc. As previously discussed, the CSR's also have IDs and PASSWORDS to ensure the 
5 security of the customer records. Further, the embodiments of the present invention 
contemplate that the CSR web application interface be only available to CSRs. 

In addition to adding or updating customer records directly into the Web site, an 
alternative embodiment enables the CSRs to access particular feeder databases or servers which 
are not part of the immediate Web site databases/servers and enter data thereto for later addition 

10 to the Web site databases/servers. In this embodiment, the files from the off-site databases or 
servers (hereafter "feeder servers") are fed into the Web site databases/servers in response to an 
established execution program. These feeder servers are as numerous as is necessary in order to 
efficiently and accurately supply customer and other relevant information to the Web site 
databases/servers. The possible configurations are too numerous to mention but one skilled in 

15 the art will recognize the many variations which flow from the following embodiments. 

The alert message text database 26 contains the notification requests based on the 
specified customer preferences. In addition to the substantive requests (e.g., notify me when 
each share of Microsoft® is $150) each request record stored in the alert message text database 
26 indicates the customer's preferred notification channel (e.g., page me with the notification at 

20 the following number (zzz-zzz-zzzz). This database utilizes information gathered through the 
customer preference databases 24. The formatted requests held in the alert message text 
database 26 are accessed and searched during the running of the execution program (e.g., 
CITIALERT™ software program), using information from the host handoff files as well as the 
rate and information databases. If an alert condition has been satisfied based on the up-to-date 

25 information, the alert message text database 26 initiates the procedure for notifying the 
customer that the request has been met. The following tables represent various schema followed 
for accessing and utilizing information from the alert message text database 26. 

The feeder servers, as well as the Web site databases/servers may be separated, 
depending on design parameters and the type of notification scenarios envisioned, into various 

30 types of categories. For example, the Web site databases/servers might include as shown in 
FIG* 1, customer preference database 24, rates and information database 30, alert message text 
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database 26, access database (not shown), and finally host-handoff files 16. These lists of 
category types are not meant to be limiting, they are merely exemplary. 

In an embodiment of the present invention, the customer preference database 24 
contains information about the customer, customer preference information, CSR information, 
5 notification method information, rates and information data, including prompt and response 
data, and display group information. Each type of information is represented in schema tables, 
such as those printed and described further with reference thereto below. The particular schema 
tables set forth below are merely exemplary and may include more or less information as 
determined by one skilled in the art for the type of notification system that is envisioned. 

10 In certain embodiments of the present invention, the customer preference database 24 

contains multiple data tables for storing and correctly logging in required data into the requisite 
datafields. In these certain embodiments, the customer preference database 24 is accessed and 
information is entered thereto by multiple entities, for multiple purposes. The following tables 
provide exemplary data schema formats for data storage within the customer preference 

15 database 24. 

Referring to TABLE 1 , the exemplary "Customer from Customer Preferences Database" 
table includes, for example, an unique customer identifier used internally by the host, customer 
name, contact information (e.g., phone/fax number(s), e-mail address, GSM or other mobile 
phone text messaging numbers), CSR ID, customer type/host affiliation (e.g. , MC or NMC), 

20 password(s), and login ID. The customer preference database retains all passwords, including 
customer passwords, in encrypted format. TABLE 1 contains a default notification method 
data field which ranks a customer's preference for notification methods, e.g. , e-mail first, GSM 
second, facsimile third, in addition to data fields containing: the date for the last time a 
modification was made to a particular customer's notification record; an activation flag for 

25 indicating whether a message is to be sent for a particular notification subscription or not e.g. , 
messages resulting from a particular notification subscription are held in queue; and an 
authentication cookie generated each time a customer retrieves their record to be updated. 
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TABLE 1 

Customer from Customer Preference Database 



Name 


Type 


Length 


Description 


Customerld 


Int 


4 


Internally generated Unique identifier of the record. 
(Primary key) 


CustomerType 


Char 


1 


"C" for CITIDIRECT or CITIGOLD customers 
"0" for non-Host customers 


Loginld 


Char 


22 


User created login ID for non-CITIDIRECT 
customers. 

Customer Identification Number (CIN) for 
CITIDIRECT customers. 


Password 


Char 


10 


User created password for non-CITIDIRECT 
customers. 

Not used for CITIDIRECT customers 


Name 


Char 


60 


Customer first name, last name and title 


Email 


Char 


50 


E-mail address to receive alerts 


GSMNumber 


Char 


20 


GSM phone number to receive alerts 


FaxNumber 


Char 


20 


Fax number to receive alerts 


DefaultNotificationMethod 


Char 


1 


'T'for E-mail 
"2" for GSM 
"3" for FAX 


LastModifiedDate 


Time 
Stamp 


8 


Date when the Customer record was last updated. 


CSRId 


Int 


4 


Reference to CSRs table. Customer's Account 
representative. 


DayPhone 


Char 


20 


Customer's day time phone number 


EveningPhone 


Char 


20 


Customer's evening time phone number 
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Name 


Type 


Length 


Description 


ActivationFlag 


Char 


1 


"Y" means alert messages will be generated for this 
subscription and Customer's will see this prompt on 
their screen. 

"N" means alert messages will not be generated for 
this subscription and Customer's will not see this 
prompt on their screen. 

This flag is used when the customer does not want 
to receive alerts yet he/she does not want to clear 
the current alert settings. 


AuthCookie 


Char 


40 


It's an application cookie generated each time 
customer fetches his/her record for update. This 
value is compared upon form submit. 



Referring to TABLE 2, the exemplary "Customer Request from Customer Preferences 
Database" table includes: customer ID (described above); identification of the processor type, 
e.g. , rates and information or host type; reference ID, e.g. , the alert to which the customer has 
5 subscribed which is dependent upon processor type; threshold flag; threshold value; notification 
method; notification limit; last notification date; and CIN for MCs, e.g. , used to access MC 
information from host database. Customer requests are separated through this table according 
to the whether the customer's request requires that the internal host databases be accessed to 
fulfill the request, e.g. , for various MC requests involving an MC's account(s) with the host, or 
10 requires that external databases be accessed to fulfill the request. This table includes a 
threshold flag data field for indicating whether a particular updated value is the same, greater, 
or lesser than a customer indicated threshold value (e.g. , interest rates, stock quotes). The 
notification limit data field holds an indicator for how often or how many times a customer 
chooses to be notified of the same alert, e.g., no limit, no alert, a specified number. 

15 
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TABLE 2 



Customer Requests from Customer Preference Database 



Name 


Type 


Length 


Description 


Customerld 


Int 


4 


Reference to a Customer record. 
(Primary key part 1 of 3) 


ProcessorType 


Char 


1 


"1" for Rates and Info type 
"2" for Host type 

This field is required since the public information 
and data obtained from the host are in different 
database. 

(Primary key part 2 of 3) 


Referenceld 


Int 


4 


This field is used to identify which alert the 
customer is subscribing to. 

Reference to a RatesAndlnforPrompts record when 
ProcessorType is "1" 

Reference to a HostlnfoPrompts record when 
ProcessorType is "2" 
(Primary key part 3 of 3) 


ThresholdFlag 


Char 


1 


For Rate type alerts it indicates the comparison 
mode of the current rate and the customer indicated 
threshold value. 
"0" for any change 

44 1 ' C j. j * . , 1 ,1 11J 1 

T if current rate is greater then threshold value 
"2" if current rate is less then threshold value 


ThresholdValue 


Float 


8 


For Rate type alerts it is the customer target value 


NotificationMethod 


Char 


1 


The notification method for this alert. 

"0" use customer's default notification method 

1 for E-mail 
"2" for GSM 
"3" for FAX 


NotificationLimit 


Int 


4 


Number of times to be notified. 

"-1" for No limit. 

"0" for no alerts will be generated 

A Positive number will generate an alert and the 

number will be decremented automatically. 
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Name 


Tvpe 

J Mr 


Length 


Description 


LastNotificationDate 


Time 
Stamp 


8 


Last time an alert was generated. 

This field is used by the Alert Message generator's 

to avoid sending duplicate messages. 


CIN 


Char 


22 


Customer Identification Number (CIN) for 
CITIDIRECT customers. This field is duplicated 
here for performance optimization (In ideal DB 
design this field should be obtained from Customers 
table Login field. 



Referring to TABLE 3, the exemplary "Customer Service Representative from 
Customer Preferences Database" table includes CSR ID which is an internally generated 
identifier unique to each CSR, name, phone number, e-mail, and a CSR manager's ID, which is 
5 the identifier for the CSR's manager. 

TABLE 3 



Customer Service Representative from Customer Preference Database 



Name 


Type 


Length 


Description 


CSRJd 


Int 


4 


Internally generated Unique identifier of the record. 
(Primary key) 


Name 


Char 


60 


Customer Representative first name, last name and 
title 


Email 


Char 


50 


E-mail address to receive copy of the alerts sent to 
the their customers. 


Phone 


Char 


20 


Phone number 


Managerld 


Int 


4 


Reference to a another CSR record which represents 
this CSR's manager 



10 Referring to TABLE 4, the exemplary "Notification Methods from Customer 

Preferences Database" table includes the data fields for the type of notification methods that are 
available and the specifications for the text that appears for the heading of each notification 
method. 
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Notification Methods from Customer Preference Database 



Name 


Type 


Length 


Description 


NotificationMethod 


Char 


1 


"1" for E-mail 








"2" for GSM 








"3" for FAX 


Heading 


Char 


20 


The textual phrase appearing on different screens 
(Web sites). 



Referring to TABLE 5, the exemplary "Rates and Information Prompts from Customer 
5 Preferences Database" table includes data fields for: an unique internal identifier for a particular 
rates and information prompt; a display group identifier; the display order; rates and 
O information types; prompt text; CSR notification; activation flag; start date; expiration date; 

lji current rate; last update date; and automatic feed identifier. 

J[f The display group identifier identifies the particular group of prompts to which this 

o! 10 particular prompt belongs. Exemplary display groups include, for example, auto loans, 
?\ Certificate of Deposit ("CD") rates, mortgage rates, stock quotes, credit card rates, etc. The 

- display order data field determines the order in which a particular prompt appears on the 

4* customer's notification screen. The rates and information type data field reflects whether the 

I Z prompt is directed toward product information only or product information with the associated 

O 15 rates. For example, product information only is a list of available mortgage loans such as 30- 
year fixed, 30-year variable, 15-year fixed, and 15-year variable, while product information 
with associated rates would include the types of mortgage loans plus the current interest rates 
for each. The prompt data field dictates the format, ej*., length, type of the notification textual 
phrase. The CSR notification data field dictates whether or not the customer chooses to have a 
20 CSR be copied on an alert. CSR notification may be desirable, for example, where the 
customer desires that he be notified of alerts by a CSR directly. The start, expiration, and last 
update date data fields indicate the date on which the notification system should begin 
generating appropriate alert messages, the date after which the system will no longer generate 
alert messages, and the date on which the current rate and info prompt record was updated, 
25 respectfully. The current rate data field contains the current rate, e.g. , interest rate, against 
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which a customer's threshold rate is compared. Finally, the auto feed identifier data field is 
used by the feeder applications (discussed above) to identify matching records during the 
process of importing rates and information from sources. 



TABLE 5 

Rates and Information Prompts from Customer Preference Database 



Name 


Type 


Length 


Description 


RatesAndlnfoPromptld 


Int 


4 


Internally generated Unique identifier of the 
record. (Primary key) 


DisplayGroupId 


Int 


4 


Reference to DisplayGroups record which 
represents this Product Prompt grouping such as 
"Auto loans" or "30 day CD rates" 


DisplayOrder 


Int 


4 


The order in which this prompt will appear on the 
Customer's screen within the DisplayGroup. 


RatesAndlnfoType 


Char 


1 


"I" for Product information only types 

"R" for Product information with associated rate 


Prompt 


Char 


100 


The textual phrase appearing on the different 
screen (Web sites) describing the alert. 


NotifyCSR 


Char 


1 


"Y" means when a message is sent to the customer 
then a copy will also be sent to the customer's 
CSR. 

"N" means do not send a copy to CSR. 


ActivationFlag 


Char 


1 


"Y" means alert messages will be generated for 
this subscription and Customer's will see this 
prompt on their screen. 

"N" means alert messages will not be generated for 
this subscription and Customer's will not see this 
prompt on their screen. 

This flag is used when the prompt is under 
construction or it is in the approval phrase. 


StartDate 


Time 
Stamp 


8 


The date from which the system will generate alert 
messages. This field has no effect on Customer 
screens, which means that if the ActivationFlag is 
"Y" then this prompt will appear on the Customer 
screen regardless of the StartDate field value. 
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Name 


Type 


Length 


Description 


ExpirationDate 


Time 
Stamp 


8 


The date after which the system will not generate 
alert messages. This field has no effect on 
Customer screens, which means that if the 
ActivationFlag is "Y" then this prompt will appear 
on the Customer screen regardless of the 
ExpirationDate field value. 


CurrentRate 


Float 


8 


The current rate to which Customer threshold 
targets are compared against. This field is valid 
only if the Rates AndlnfoType is "R". 


LastUpdateDate 


Time 
Stamp 


8 


Last time this record or its corresponding response 
was updated. 

This field is used by the Alert Message generator's 
to avoid sending duplicate messages. 


AutoFeedld 


Char 


10 


This field is used by Feeder applications to identify 
matching records during import process. 



Referring to TABLE 6, the exemplary "Rates and Information Responses from 
Customer Preference Database" table includes data fields for: an unique internal identifier for a 
particular rates and information response; the corresponding unique internal identifier for the 
5 particular rates and information prompt; notification method; subject; response detail; and 
activation flag. 

The "Rates and Information Responses from Customer Preference Database" details the 
corresponding response information for the "Rates and Information Prompts from Customer 
Preference Database." Consequently, the responses are assigned an identifier that is linked to 
10 the prompt identifier representing the prompt to which it is responding. The subject data field 
dictates the textual phrase that appears in the response message heading, such as the 
subject line in a standard e-mail message. The response detail data field dictates the textual 
phrase that appears in the body of the response message, e^g., such as the body of a standard e- 
mail message. 

15 
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Rates and Information Responses from Customer Preference Database 



Name 


Type 


Length 


Description 


RatesAndlnfoResponseld 


Int 


4 


Internally generated Unique identifier of the 
record. (Primary key) 


RatesAndlnfoPromptld 


Int 


4 


Reference to a RateAndlnfoPrompts record which 
represents the prompt (question) to this response. 


JNOUIlCallOniVlcUlUU 


Char 


1 


"0" for default response for all methods 
"1" for E-mail 
"2" for GSM 
"3" for FAX 


Subject 


Char 


100 


The textual phrase appearing on the Response 
message heading. This is the same as standard E- 
mail subject text. 


ResponseDetail 


Var 
Char 


1024 


The textual phrase appearing on the Response 
message body. This is the same as standard E-mail 
body text. 


ActivationFlag 


Char 


1 


"Y" means this response is ready to be sent to 
customers. 

"N" means this response is not ready to be sent to 
customers.. 

This flag is used when the response is under 
construction or it is in the approval phrase. 



Referring to TABLE 7, the exemplary "Display Groups from Customer Preference 
Database" table includes data fields for: a display group identifier; heading; source database; 
and the display order. The source database indicates the database which stores the display 
groups, e.g. , the customer preference database. 
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TABLE 7 



Display Groups from Customer Preference Database 





TvDe 


Length 


Description 


ni^nlavOrminTH 


Int 


4 


Internally generated Unique identifier of the record. 
(Primary key) 


Heading 


Char 


80 


The textual phrase appearing on different screens 
(Web sites). This field represents the Product 
grouping such as "Auto loans" or "30 day CD 
rates". 


SourceDB 


Int 


4 


"1" for Customer Preference Database 


DisplayOrder 


Int 


4 


The order in which this product grouping will 
appear on the Customer's screen. 



In an embodiment of the present invention, the rates and information database 30 
5 contains promotional content such as current rates and upcoming specials. This database keeps 
generic notification options available to all customers. This database can also be used to 
broadcast critical messages to selected customers. For example, if a customer has indicated a 
specific price at which the customer wishes to purchase a specified amount of stock or has 
requested notification in the event of a particular amount of variation in a foreign exchange rate, 
1 0 the rates and information database contains this type of information. 

In an embodiment of the present invention, the alert message text database 26 is used to 
keep the content of the text of the alert messages (provided by the host handoff files database 
16) in an efficient format. Only the latest handoff file content is retained in the alert message 
text database 26. 

15 Referring to TABLE 8, the exemplary "Host Information Prompts from Alert Message 

Text Database" table includes data fields for: an unique internal identifier for a particular host 
information prompt; a display group identifier; the display order; prompt text; CSR notification; 
activation flag; start date; expiration date; message code; last update date; and automatic feed 
identifier. 

20 The majority of the data fields from TABLE 8 are described with reference to at least 

TABLE 5. Additionally, the message code is an action code that is set by the host and 
represents the host identified event which the customer has selected for alert purposes. This 
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message code is used by the alert message generator to map host event records to host 
information prompt records. 

TABLE 8 



Host Information Prompts from Alert Message Text Database 



Name 


Type 


Length 


Description 


HostlnfoPromptld 


Int 


4 


Internally generated Unique identifier of the 
record. (Primary key) 


DisplayGroupId 


Int 


4 


Reference to DisplayGroups record which 
represents this Product Prompt grouping such as 
"Checking accounts" or "Money Market 
Accounts" 


DisplayOrder 


Int 


4 


The order in which this prompt will appear on 
the Customer's screen within the DisplayGroup. 


Prompt 


Char 


100 


The textual phrase appearing on the different 
screen (Web sites) describing the alert. 


NotifyCSR 


Char 


1 


"Y" means when a message is sent to the 
customer then a copy will also be sent to the 
customer's CSR. 

"N" means do not send a copy to CSR. 


ActivationFlag 


Char 


1 


"Y" means alert messages will be generated for 
this subscription and Customer's will see this 
prompt on their screen. 

"N" means alert messages will not be generated 
for this subscription and Customer's will not see 
this prompt on their screen. 
This flag is used when the prompt is under 
construction or it is in the approval phrase. 


StartDate 


Time 
Stamp 


8 


The date from which the system will generate 
alert messages. This field has no effect on 
Customer screens, which means that if the 
ActivationFlag is "Y" then this prompt will 
appear on the Customer screen regardless of the 
StartDate field value. 
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Name 


Type 


Length 


Description 


ExpirationDate 


Time 
Stamp 


8 


The date after which the system will not generate 
alert messages. This field has no effect on 
Customer screens, which means that if the 
ActivationFlag is "Y" then this prompt will 
appear on the Customer screen regardless of the 
ExpirationDate field value. 


MessageCode 


Float 


8 


The action code set by the Host, which 
represents this event For example "11111" 
means overdraft. The Message code is used by 
the host alert message generator to map a 
HostEvent record to HostlnfoPrompt record. 


LastUpdateDate 


Time 
Stamp 


8 


Last time this record or its corresponding 
response was updated. 

This field is used by the Alert Message 
generator's to avoid sending duplicate messages. 


AutoFeedld 


Char 


10 


This field is used by Feeder applications to 
identify matching records during import process. 



Referring to TABLE 9, the exemplary "Host Information Responses from Alert 
Message Text Database" table includes data fields for: an unique internal identifier for a 
particular rates and information response; the corresponding unique internal identifier for the 
particular rates and information prompt; notification method; subject; response detail; and 
activation flag. The description of these data fields is found with reference to TABLE 6. 

TABLE 9 



Host Information Responses from Alert Message Text Database 



Name 


Type 


Length 


Description 


HostlnfoResponseld 


Int 


4 


Internally generated Unique identifier of the 
record. (Primary key) 


HostlnfoPromptld 


Int 


4 


Reference to a HostlnfoPrompts record which 
represents the prompt (question) to this response. 
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Name 


Type 


Length 


Description 


NotificationMethod 


Char 


1 


"0" for default response for all methods 
"1" for E-mail 
"2" for GSM 
"3" for FAX 


Subject 


Char 


100 


The textual phrase appearing on the Response 
message heading. This is the same as standard E- 
mail subject text. 


ResponseDetail 


Char 


1024 


The textual phrase appearing on the Response 
message body. This is the same as standard E- 
mail body text. 


ActivationFlag 


Char 


1 


"Y" means this response is ready to be sent to 
customers. 

"N" means this response is not ready to be sent to 
customers.. 

This flag is used when the response is under 
construction or it is in the approval phrase. 



Referring to TABLE 10, the exemplary "Host Event From Alert Message Text 
Database" table includes data fields for: an unique identifier for identifying a host event; 
account number; product type code; sub product code; currency code; CIN; message code; 
5 current value; as of date; last update date; and notes. 

In addition to previously defined data fields, further data fields defined through TABLE 
10 include identifiers for identifying a customer through the customer's relationship with the 
host. For example, account number, product type, sub product type, and currency code 
represent four (4) data fields that link a customer to the host. In a particular exemplary 
10 embodiment, a customer has a checking account, e.g. , account number, with the host as well as 
a car loan, ejj., product type, wherein the car loan is a 5 year loan at an 8.0% fixed interest rate, 
e.g. , sub product type, calculated in U.S. dollars, ej*., currency. The notes and as of date data 
fields are for information which is only merged with the response detail or the message text 
when messages are sent to the customers. For example, the notes data field is used to send 
15 account specific information such as current balance. 
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TABLE 10 



Host Event From Alert Message Text Database 



]\Tq tn a 


type 


T . Aiiot Vi 


FIacpi*i nf inn 


HostEventld 


Int 


4 


Internally generated Unique identifier of the 

1 Gl/Ul U.. y± 1 lillal y IvCjr J 


AccountNumber 


Char 


22 


Account number. Part 1 of 4 to uniquely identify 
a rplntinn^liiri with l-Trwt 

<X 1 tldLUJllOlllLF Willi liuol. 


ProductTypeCode 


Char 


3 


Product type. Part 2 of 4 to uniquely identify a 
relationship with Host. 


SubProductTypeCode 


Lnar 


1 


Sub product type. Part 3 of 4 to uniquely identify 
a relationship with Host. 


CurrencyCode 


Char 


3 


Currency Code. Part 4 of 4 to uniquely identify a 
relationship with Host. 


CIN 


Char 


22 


Customer Identification Number. This field is 
used to identify the specific Customer request 
record. 


MessageCode 


Float 


8 


The action code set by the Host, which 
represents this event For example "11111" 
means overdraft. The Message code is used by 
the host alert message generator to map a 
HostEvent record to HostlnfoPrompt record. 


CurrentValue 


Float 


8 


The current value to which Customer threshold 
targets are compared against. For example if a 
customer wants to be notified if his/her balance 
is below certain amount. 


AsUlDate 


Time 
Stamp 


o 
O 


This field is for information only which will be 
merged with the Response Detail (body) when 
messages are sent to the customers. 


LastUpdateDate 


Time 
Stamp 


8 


Last time this record or its corresponding 
response was updated. 

This field is used by the Alert Message 
generator's to avoid sending duplicate messages. 
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Name 


Type 


Length 


Description 


Notes 


Char 


120 


The textual phrase, which will be merged with 
the Response Detail (body) when messages are 
sent to the customers. This field can be used to 
send account specific data such as current 
balances. 



Referring to TABLE 11, the exemplary "Display Groups from Alert Message Text 
Database" table includes data fields for: a display group identifier; heading; source database; 
and the display order. The source database indicates the database which stores the display 
5 groups, e.g. , the host handoff database. 

TABLE 11 



Display Groups from Alert Message Text Database 



Name 


Type 


Length 


Description 


DisplayGroupId 


Int 


4 


Internally generated Unique identifier of the 
record. (Primary key) 


Heading 


Char 


80 


The textual phrase appearing on different screens 
(Web sites). This field represents the Product 
grouping such as "Checking accounts" or "CDs". 


SourceDB 


Int 


4 


"2" for Host handoff database 


DisplayOrder 


Int 


4 


The order in which this product grouping will 
appear on the Customer's screen. 



10 Referring to TABLE 12, the exemplary "Alert Messages from Alert Message Text 

Database" table includes data fields for: an alert message identifier; customer ID; customer 
type; notification method; processor type; reference identifier; create date; sent date; subject; 
response detail; and CSR notification. 

The alert messages are uniquely identified to the database through an identifier. In 

15 addition to previously defined data fields, in order to formulate specific alert messages the 
requesting customer is identified through a customer ID, the customers status as an MC or 
NMC is identified, the notification method is identified, the processor type is identified, and a 
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reference ID is used to identify which alert the customer has selected. Further, the create and 
sent dates identify when the alert message was created and sent, respectively. 

TABLE 12 



Alert Messages from Alert Message Text Database 



Name 


Type 


Length 


Description 


AlertMessageld 


Int 


4 


Internally generated Unique identifier of the 
record. (Primary key) 


Customerld 


Int 


4 


Reference to a Customer record. 


CustomerType 


Char 


1 


"C" for CITIDIRECT or CITIGOLD customers 
"0" for non-Host customers 


NotificationMethod 


Char 


1 


The notification method for this alert. 

"0" use customer's default notification method 

"Pfor E-mail 

"2" for GSM 

"3" for FAX 


ProcessorType 


Char 


1 


"1" for Rates and Info type 
"2" for Host type 

This field is required since the public information 
and data obtained from the host are in different 
database. 


Referenceld 


Int 


4 


This field is used to identify which alert the 
customer is subscribing to. 

Reference to a RatesAndlnforPrompts record when 
ProcessorType is "1" 

Reference to a HostlnfoPrompts record when 
ProcessorType is "2" 


Createdate 


Time 
Stamp 


8 


Timestamp when this record is created 


SentDate 


Time 
Stamp 


8 


Timestamp when alert was sent 


Subject 


Char 


100 


The textual phrase appearing on the Response 
message heading. This is the same as standard E- 
mail subject text. 
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Name 


Type 


Length 


Description 


ResponseDetail 


Var 
Char 


1024 


The textual phrase appearing on the Response 
message body. This is the same as standard E-mail 
body text. 


NotifyCSR 


Char 


1 


"Y" means when a message is sent to the customer 
then a copy will also be sent to the customer's 
CSR. 

"N" means do not send a copy to CSR. 



In certain embodiments of the present invention, the access database is used to give 
database access to all other applications within the notification system. 

Referring to TABLE 13, the exemplary "Access from Access Database" table includes 
data fields for: an access ID; login ID; password; last changes date; connection string; and 
5 password change interval. The access database gives a requesting database/server with an 
appropriate access identifier, the proper database connection string, database login ID, and 
password for the database that is sought to be accessed. The table also tracks password changes 
through the last changes date data field and contains the value for the time intervals at which the 
password is required to be changed for security reasons through the password change interval 
10 data field. 



TABLE 13 
Access from Access Database 



Name 


Type 


Length 


Description 


Accessld 


Int 


4 


Internally generated Unique identifier of the 
record. (Primary key) 


Loginld 


Char 


20 


Database login name 


Password 


Char 


20 


Database login password 


LastChangedDate 


Time 
Stamp 


8 


Last time the Login password was changed 


ConnectionString 


Char 


120 


Database connections string 


PasswordChangelnterval 


Int 


4 


Number of days when a new password should 
be generated for this login 
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In certain embodiments of the present invention, servers are either accessed or perform 
an accessing function in order to update one or more of the databases described above. In order 
to provide timely notifications to customers, it is necessary to ascertain and synthesize the most 
up to date information that is available. As was discussed previously, data may be collected 
5 from a variety of different sources and fed into a variety of different databases or files. The 
term "servers" is a generic term utilized to describe any and all sources of data and information 
which may be used to update the specific databases described above. These servers could be 
databases, servers, or direct data links, such as people, entering information in real-time or 
networks. 

10 The tables and descriptions set forth herein are merely meant to be exemplary 

embodiments of the present invention and are not intended to be limiting. One skilled in the art 
recognizes the many variations and embodiments which fall within the scope of the invention. 
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